PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/USEnet Digests/USEnet Vol. 4/USEnet 4.59

Text File | 1988-06-15 | 37.0 KB | 913 lines | [TEXT/ttxt]

 9-May-88 21:57:08-PDT,38723;000000000000
Return-Path: <[e-mail]>
Received: from RELAY.CS.NET by SUMEX-AIM.Stanford.EDU with TCP; Mon, 9 May 88 21:56:16 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa02268; 10 May 88 0:05 EDT
Received: from relay.cs.net by RELAY.CS.NET id aa03597; 10 May 88 0:01 EDT
Received: from sdr.slb.com by RELAY.CS.NET id ab03378; 9 May 88 23:42 EDT
Date: Mon, 9 May 88 09:22 EDT
From: Jeffrey Shulman <[e-mail]>
Subject: Usenet Mac Digest V4 #59
To: [e-mail], [e-mail]
X-VMS-To: in%"[e-mail]",in%"[e-mail]"

Date: Mon  9 May 88 09:21:56-GMT
From: Jeff Shulman <SHULMAN@SDR>
Subject: Usenet Mac Digest V4 #59
To: Usenet-List: ;
Message-ID: <579169316.0.SHULMAN@SDR>
Mail-System-Version: <VAX-MM(218)+TOPSLIB(129)@SDR>

Usenet Mac Digest     Friday, May 6, 1988            Volume 4 : Issue 59

Today's Topics:
     Re: Dual Video Card Problem
     Print Monitor Problem
     Tidbits from InfoWorld
     Re: Has anyone ordered from HardWareHouse?
     Interleaf on the Mac
     Wanted: Tektronix 4027 emulator
     Programmer's Extender vs. MacExpress...
     Goin' Crazy on a Mac, or, How I Love MPW "GlobalData" (2 messages)
     Re: Macsbug won't work with my 19" screen
     Replys to: Developer Quality C Compiler w/inline Assembly
     Re: Programmer's Extender vs. MacExpres
     Re: Physical Storage Amounts on Different Hard Disks (Size of Folders)
     Word Perfect for the Mac
     Info on EMAC hard drives
     A/UX AppleTalk printing

----------------------------------------------------------------------

From: [e-mail] (Eric K. Olson)
Subject: Re: Dual Video Card Problem
Date: 2 May 88 16:22:33 GMT
Organization: Lexington Software Design, Lexington, MA

What you are experiencing is due in part to poor programming in the
software you are using to test, and in part due to Apple's not providing
a simple way to do things correctly.

Everything on a Mac II has a CLUT.  PixMaps (multi-bit Bitmaps),
Windows, Cursors, and Video Cards all have CLUT (color lookup tables).
In order to display a PixMap on a monitor EXACTLY the way it was
intended to look, the video card's CLUT must match the PixMap's CLUT.
Apple provides two disjoint methods of setting the video card's clut:
The Color Manager, and the Palette Manager.

In the Color Manager model, the programmer explicitly sets the colors in
the video card's CLUT.  If there are two video cards, the programmer
must set both CLUTs appropriately.  In the Palette Manager model, the
programmer associates a CLUT with a window and calls ActivatePalette()
in response to a window becoming frontmost.  The Palette Manager
determines which video card(s) the window exists on and sets the CLUTs
appropriately.

For 256-gray-level images, the CLUT should just be set to a ramp, where
Black = R 0, G 0, B 0, and White = R 65536, G 65536, B 65536, and an
even distribution of Grays in between.

Unfortunately, Apple has provided no way to tell the Palette Manager
that a window requires EXACTLY a particular CLUT, with entries in a
particular order.  Had Apple done this (and had they released the
Palette Manager interfaces earlier), many programs that don't work on
multiple screens now might have had a fighting chance.

My own code goes to great pains to emulate the Palette Manager's
behavior, but with the ability to set a video card's CLUT EXACTLY.

It is possible to get the Palette Manager to set all the colors in the
video card's CLUT, but not in a particular order.  This slows down
Blitting to the screen significantly.

Most code just sets the MainDevice's CLUT explicitly (this is what you
are seeing).  Blits onto other screens (whose CLUTs are still the Apple
default) show about 12 Grey levels, because that's how many are in the
default CLUT. The system software is VERY good about always showing you
the best fit it can manage for the CLUTs it has to work with.

There are other problems with multiple screens:  the most annoying is
that Pop-Up menus ALWAYS appear on the screen with the MenuBar.
Apparently the Menu Manager doesn't know how to deal with multiple
screens.

Getting your software to work well with multiple screens is no easy
task.
--
-Eric
      Lexington Software Design:  Tomorrow's Software Yesterday

Eric K. Olson     [e-mail]     harvard!endor!olson     D0760
   (Name)                (ArpaNet)                 (UseNet)        (AppleLink)


------------------------------

From: [e-mail] (Edward Olsen)
Subject: Print Monitor Problem
Date: 2 May 88 17:37:38 GMT
Organization: Image Analysis Systems Grp, JPL

I have encountered a problem with Print Monitor v1.0 which I think the
Mac community should know about.  It became apparent when I used Cricket
Draw v1.1 to make some figures.  I found that the system crashed, or the
mouse froze up, or applications (Print Monitor among them) "unexpectedly
quit" just after the postscript output file was generated.

These problems did not occur when I ran the same printout under Finder
(not Multifinder).  I then found that the 10K cricket draw document was
generating a 108K spooled print file!  Since I had configured my Print
Monitor application to use 120K of memory, I was just on the hairy
limit.  Once I increased my Print Monitor partition to 200K, all
problems ceased.  The document contained a small bitmap, some shaded
circles and some arcs.  Users of applications which generate postscript
files (not just Cricket Draw users) should be aware of this problem with
Print Monitor.

Until Apple comes out with a fixed version of Multifinder and Print
Monitor, I suggest either increasing the Print Monitor application
memory size to at least 200K, avoid Multifinder entirely, or use another
print spooler.
                   Ed Olsen


------------------------------

From: [e-mail] (Chuq Von Rospach)
Subject: Tidbits from InfoWorld
Date: 2 May 88 20:20:16 GMT

I don't normally read InfoWorld, but since there has been some
discussion of Mac IPC recently, the headline on the 5/2 issue ("Mac OS
to Support Links Between Applications") caught my eye, so I borrowed a
copy.

There are some interesting tidbits I thought I'd pass along.

o Apple's developing a set if interprocess communication procedures for
    release about a year from now. Something on the order of a smart
    clipboard.

o With system release 7.0 (6.0 is due to be released any time, 7.0 this
    winter? maybe?) multifinder will be the default, "replacing the
    finder".

    [does this mean that finder functionality gets merged into MF
    and the finder process goes away? who knows....]

    Also, the likely minimum memory configuration supported with this
    release will be 2Meg. They better hope SIMM prices drop.... You've
    been warned, start planning that memory upgrade now, folks. you're
    going to want it....

o On other fronts, Think Technologies has taken some ribbing on the net
    for the early publication of their LightSpeed C ad in MacTutor.
    This was actually done, without authorization, by the Ad Agency.

    Well, Think's fired their ad agency for it. Which gives you an
    idea what Think thinks of vaporware. [Congrats to Think for holding
    to their ethics. Clap, clap, clap, clap.....]

o Microsoft seems to be worried about FullWrite Professional (I wonder
    why...). Microsoft is negotiating to ship a copy of SuperPaint with
    each copy of Word 4.0 (they haven't announce 4.0, but...)

    [Interesting marketing touch. SuperPaint is about to be replaced
    (mid-summer) with SuperPaint2, which looks like it's going to go
    up against Illustrator and FreeHand. If they start shipping
    SuperPaint with Word, Silicon Beach continues to get a revenue
    stream from the older program, and if they allow a reduced price
    upgrade to the more powerful program....

    Word wins by getting a good graphic program to fight FWP's graphic
    capabilities. Silicon Beach gets new life for an old program, and
    a chance to convince folks to upgrade to their newer one. End-users
    win,because they get SuperPaint as part of the package.

    And if you thought Microsoft had the word processing market
    sewed up, you can think again... Microsoft doesn't seem to be taking
    any chances....]

Now, go start putting money away for that memory upgrade....
--
Chuq Von Rospach            [e-mail]        Delphi: CHUQ

                              This signature is currently under construction.
                           We are sorry for any inconvenience this may cause.


------------------------------

From: [e-mail] (Evan Bauman)
Subject: Re: Has anyone ordered from HardWareHouse?
Date: 3 May 88 02:46:41 GMT
Organization: Univ. of Notre Dame

In article <[e-mail]>,
[e-mail] (Scott Snyder) writes:
> Hi,
>     I'm seriously considering getting a CMS-MacStack 60 Hard disk from the
> HardWareHouse that is advertised in the back of the May MacUser. The price seems
> right but I am concerned about ordering from a mail order house I have no
> information about.  If anyone knows anything about this mail order house (they
> operate out of Philadelphia, PA) please e-mail me your personal experiences
> and I will summarize to the net if I get enough responses.

Our department has ordered 4 of the CMS Pro 60-ii internal disks from
Hardware House and one of the external MacStack 60's.  The price was
fantastic and delivery was within 1 week.  No complaints here.

Of course, we're just satisfied customers.

    Evan Bauman
    Univ. of Notre Dame
    ..!iuvax!ndcheg!evan


------------------------------

From: [e-mail] (Bill O)
Subject: Interleaf on the Mac
Date: 1 May 88 23:43:24 GMT
Organization: Northeast Parallel Architectures Center, Syracuse NY

A while back I solicited comments concerning Interleaf  Publishing
Software on the Mac.  I've had a few responses, so, as promised, here is
a summary.


WHAT'S MISSING/NOT MISSING IN THE MAC VERSION
=============================================
>From SDL...
They use their own fonts, which is fine by me since they include just
about everything in the LaserWriter Plus.  Everything from the Sun is
there except the eqn package ... but MathType or similar packages get
the job done. ------

Editor's note: Interleaf apparently has plans to port eqn in the future.
 This summer there will be an interim release of Publisher that will
interface with other Mac equation packages. Note that the Mac also
doesn't have continuous tone image editing.  The Mac version also only
supports PostScript fonts and devices. ------

CONCERNING THE MAC USER INTERFACE =================================

>From SDL...
Getting used to the difference in their window and menu system from the
Mac's takes about a day, and even though I'm a Mac programmer who spend
mucho time doing things according to Apple's User Interface Rules, I
really like much of the IL interface.   ------

>From FAD...
As all the Mac reviewers have complained, it's not the Mac interface. To
get the function of a three-button mouse, they require you to hold down
command and click (equivalent to the middle mouse button) or shift-click
(the right button).  All the keyboard action is a little frustrating
when you're working with the mouse.  Double clicking would have been
nice. ------

>From Eph...
My immediate manager has Interleaf on his Mac II, and all of us in my
office have it on our Sun 3/50's.  The implementations are fastidiously
identical, which is to say that Interleaf on the Mac is not a Mac
program.  It's an alien program that runs on the Mac hardware. ------

CONCERNING SPEED/PERFORMANCE ============================

>From SDL...
I am currently running Interleaf Pub on a Mac II w/ 8Mb.  I run w/ a 1Mb
ram cache usually.  ... I have been very impressed with the speed of
ILP.  Their windows are blazing and the WP makes FullWrite and Word look
sick.  It can scroll faster than I can click or drag.

All printing is done in PostScript and is VERY fast.  I have ~150 pages
of bitmap figures and they print so fast compared to other Mac software
(including doing a straight screen dump from the System!), that IL must
be doing some very good PS hacking.

Their menus, windows, etc. are simply the fastest stuff I've ever seen
on a Mac.  I wish Apple's code was this fast... ------

>From Eph...
Performance is quite good.   ------

INTEGRATION/COMPATIBILITY WITH MAC ENVIRONMENT & OTHER SYSTEMS
==============================================================

>From SDL...
It is file compatible w/ IL on Sun/RT/etc. and can run in a
heterogeneous network environment.  You can bring PICTs and TEXT from
the Mac side over to IL either through a DA or directly from the Mac
clipboard which is converted to a doc in the IL clipboard when you start
IL.

IL doesn't support multifinder, but it does run in a 6144k partion, but
sometimes has problems, nothing terminal, but under finder it is SOLID.
------

>From FAD...
They convert everything you paste from the clipboard, which works fine,
but you can't have other applications open at the same time. You have to
use DAs or the Scrapbook to get graphics from external sources. ------

MONITOR SIZE ============

>From SDL...
I'm doing my thesis with it and even on a 12" Apple monochrome screen it
is great. ------

>From Eph...
A small screen is a big problem, especially if you're used to a larger
one, so ... quickly got a larger monitor. ------

OVERALL IMPRESSIONS ===================

>From SDL...
They do need to make some adaptations for the Mac and add a thesaurus,
etc., but I'm very happy with it.

IL really makes Word and FW look like toys in comparison.  If they
improve their bitmap editor it will be even better.

This is the first software in the Mac market that I ever known to ship
on the announced date and to be ABSOLUTELY SOLID.  We paid $1k for a
university copy, but I would gladly pay $2,495 for this product for
professional use.

Yup, I like it. ------

>From FAD...
We've used Interleaf on Suns for a while, and now have it on a Mac II
also.  It's very nice. ------

RESPONSIVENESS OF COMPANY =========================

>From FAD...
We have a list of general gripes about Interleaf -- but a lot of these
will be addressed by release 4.0, which is due in a few months.  They
are next door to us, and we've made direct contact with engineers, which
helps with questions and responsiveness to suggestions. ------

>From Eph...
We're not directly connected to Interleaf, but we do deal with them more
than the average customer.  They're about two blocks from us, the wife
of one of my office-mates works there, and we had a bunch of their
engineers over for lunch to discuss user-interface problems last week.
They seem to be quite interested in what real users have to say about
the product. ------


Credits: SDL: Steven D. Leeke ([e-mail]) Stanford
University
         FAD: Franklin A. Davis ([e-mail]) Thinking Machines Corp.
         Eph: Ephraim ([e-mail]) Thinking Machines Corp.

Many thanks to the contributors.
--
Bill O'Farrell, Northeast Parallel Architectures Center at Syracuse University
([e-mail])


------------------------------

From: [e-mail] (Thomas Fruin)
Subject: Wanted: Tektronix 4027 emulator
Date: 2 May 88 21:54:41 GMT
Organization: uvabick


Does anyone know of a Tektronix 4027 emulator for the Macintosh II?  I
need the 16 colors - VersaTerm PRO is not good enough, because it only
has 8 colors.

Please reply by mail - if anything comes up I'll summarize.

-- Thomas Fruin

   [e-mail]                  University of Leiden
   [e-mail]                   University of Amsterdam
   hol0066.AppleLink
   2:512/114.FidoNet                     The Netherlands


------------------------------

From: [e-mail] (Jeffrey A. Sullivan)
Subject: Programmer's Extender vs. MacExpress...
Date: 30 Apr 88 19:31:15 GMT
Organization: Decision Systems Lab., Univ. of Pittsburgh, PA.

Has anyone had any experience with Programmer's Extender or MacExpress
or any of these COMMERCIAL generic application/apptools kinds of
products?  I am assuming that they are like enhanced versions of
transskel with more functionality and the like.  I enjoy
transskel/edit/display/blob, but there are things i'd like to do that
they can't and which bomb when I work on them. For me, getting the
programs done is more important than really understanding the innards of
the Mac II.  Oh, by the way, are they both Mac II compatible?


--
..........................................................................
Jeffrey Sullivan              | University of Pittsburgh
[e-mail]          | Intelligent Systems Studies Program
[e-mail], [e-mail] | Graduate Student


------------------------------

From: [e-mail] (Garry Wiegand)
Subject: Goin' Crazy on a Mac, or, How I Love MPW "GlobalData"
Date: 30 Apr 88 21:11:47 GMT
Organization: Cornell Engineering && Ithaca Software, Inc.

We are attempting - and have been attempting for some time now - to port
our large 3D graphics subroutine library onto the Mac. The Mac is
driving us rapidly nuts.

We have worked around the bugs in Quickdraw, the obscurities in the
documentation, the lack of a usable debugger, the solitary system error
message (a round black object with a fuse :-), and *some* of the
perversities of MPW/Aztec/Lightspeed/etc etc etc. We have not yet
succeeded in working around/through the bureaucracy at Apple so that we
can ask questions "officially". Now we've run into a wall, and we could
use some help.

The MPW C compiler is not very good, but unfortunately it is Apple's
choice, so it has to be the primary focus of our Mac support. MPW C has
the custom of loading the A5 register with a pointer to all of "global
data" during program start-up. All accesses are then via a 15-bit offset
to A5, which never changes.  ("Global data" consists of everything
that's not code and not dynamically allocated - global variables, static
variables, strings, and floating-point constants (12 bytes each!).)
The bottom line is that with MPW you can only ever have 32K (2^15) of
fixed data. Doesn't matter if your Mac has megabytes and megabytes of
memory; 32K is the static data limit.

Question 1:
        Anybody know of any magic workarounds to this limit, short of
        damaging all of our source code?

Question 2:
    Has anyone heard any rumors that this MPW bug might be fixed
        sometime soon? (There's a rumored "3.0" release coming, but as
        far as we can tell a "32K" fix is not included in it.)

Question 3:
        We *might* be able to squeeze our own data into 32K, but the
        user program that links to our library would surely push
        things back over the limit. If we could separate the user's A5
        usage from our library's, then we might be OK. Has anyone ever
        gone through the exercise of segmenting a program into *multiple
        separate code resources* on the Mac?  (The system apparently
        does this all the time, but the details of the "message-
    passing" involved are obscure to us.)

Any help would be greatly appreciated.

garry wiegand   ([e-mail] - ARPA)
        (garry@crnlthry - BITNET)

PS:  As much as I'm complaining about Apple's software, they're the only
PC/workstation company I've encountered so far that actually *cares*
about software, and thinks about how things *ought* to be done - they
don't just copy boring 15-year-old Unix ideas. "Inside the Mac" is
interesting reading even if you never intend to use a Mac.

(Good ideas unfortunately do not automatically make a system "programmer
 friendly". "Ghetto" debugging, complicated data structures, no error
 checking, and no error messages - Apple, you're a bunch of nitwits!)


------------------------------

From: [e-mail] (Pierce T. Wetter)
Subject: Re: Goin' Crazy on a Mac, or, How I Love MPW "GlobalData"
Date: 1 May 88 08:25:06 GMT
Organization: California Institute of Technology

In article <[e-mail]> [e-mail]
writes:
>We have worked around the bugs in Quickdraw, the obscurities in the
    What bugs?
>The MPW C compiler is not very good, but unfortunately it is Apple's
>choice, so it has to be the primary focus of our Mac support. MPW C
>has the custom of loading the A5 register with a pointer to all of
>"global data" during program start-up. All accesses are then via a
>15-bit offset to A5, which never changes.  ("Global data" consists of
>everything that's not code and not dynamically allocated - global
>variables, static variables, strings, and floating-point constants (12
>bytes each!).)   The bottom line is that with MPW you can only ever
>have 32K (2^15) of fixed data. Doesn't matter if your Mac has
>megabytes and megabytes of memory; 32K is the static data limit.
   Actually this is common to all languages under MPW. Global data is
referenced as an offset from a5. On the 68000 thats 16 bits, on the 020
its 32 bits. Read the object code format description if you want more
details. I agree it can be annoying, but there are some things to
remember.

      1. Static variables consist of a bunch of DC.L statements.
Therefore
          20K of empty static arrays will take up 20K of disk space.
      2. Quickdraw globals have to be addressed this way anyways.
>
>Question 1:
>        Anybody know of any magic workarounds to this limit, short of
>        damaging all of our source code?
   If its for a 68020 machine, you might be able to ignore the messages
produced by link, but don't quote me.

>Question 2:
>    Has anyone heard any rumors that this MPW bug might be fixed
>        sometime soon? (There's a rumored "3.0" release coming, but as
>        far as we can tell a "32K" fix is not included in it.)

>Question 3:
>        We *might* be able to squeeze our own data into 32K, but the
>        user program that links to our library would surely push
>        things back over the limit. If we could separate the user's A5
>        usage from our library's, then we might be OK. Has anyone ever
>        gone through the exercise of segmenting a program into *multiple
>        separate code resources* on the Mac?  (The system apparently
>        does this all the time, but the details of the "message-
>    passing" involved are obscure to us.)
    Segmenting a program simply requires a "#define ___SEG___ segname"
message. All procedures following such a message will be placed in
'segname' by the linker.
   This won't help anyways. The real problem is that the 68000 can only
have a 16 bit offset from a5. Note that the limit should be 64K and a5
should point to the center of your data, but no compiler writers are
smart enough to think of that.
   As for your data, you're probably allocating large arrays. Why not
just  allocate a pointer and write some initilization code to allocate
the space at startup. Since this is a library you might want to do the
following:

Replace static double  MEMORY[10000000000] with static double *MEMORY=0;


{  if (MEMORY=NULL) MEMORY=malloc( 10000000000* sizeof(double))
 MEMORY[5]=PI; }

>(Good ideas unfortunately do not automatically make a system "programmer
> friendly". "Ghetto" debugging, complicated data structures, no error
> checking, and no error messages - Apple, you're a bunch of nitwits!)
    They do give you the number though, you just have to look it up.
 (If its listed. My Favorite Unlisted Error: -4001, LaserPrinter out of
Paper)
--
Pierce Wetter
----------------------------------------------------------------
[e-mail]     Race For Space Grand Prize Winner.
-----------------------------------------------------------------
   Useless Advice #986: Never sit on a Tack.


------------------------------

From: [e-mail] (Stew Rubenstein)
Subject: Re: Macsbug won't work with my 19" screen
Date: 2 May 88 17:54:17 GMT
Organization: Aiken Computation Lab Harvard, Cambridge, MA

In article <[e-mail]> [e-mail] (Kevin O'Gorman) writes:
>Anybody know how to get TMON, or another solution to my problem?

TMON is available from APDA, and from its publisher, ICOM Simulations.
ICOM's phone number is 312-520-4443.

MacsBug 6.0B1 was just released last week.  It is available from APDA.

APDA's phone number is 206-251-6548.  If you're not a member, you ought
to join.  They are very poor at order processing, but are the only
source for many Macintosh programming tools.
--
Stew Rubenstein
Cambridge Scientific Computing, Inc.
UUCPnet:    seismo!harvard!rubenstein            CompuServe: 76525,421
Internet:   [e-mail]       MCIMail:    CSC


------------------------------

From: [e-mail] (Daniel J Pezely)
Subject: Replys to: Developer Quality C Compiler w/inline Assembly
Date: 2 May 88 16:55:49 GMT
Organization: University of Delaware

A few days ago I posted a request for information about developer
quality C compilers.  I also mentioned a few errors which I was having,
but they were mostly silly mistakes of typing or translation from Aztek
C code to LSC.

Here are some of the responces which I received:

>From: [e-mail] (Pierce T. Wetter)

. . . In general I've noticed this: People who've programmed a lot on
other computers tend to love MPW (instant batch files). People who
program the mac mostly like LSC because: its quick, you don't need to
worry about make files, and it segments your code nicely. (In that
order.) However, I've converted a few people from LSC to MPW and I've
noticed that once they get up and running, they don't mind it all that
much (Warning: LSC int=16 bits  MPW int=32, use short when you want a
pascal int). . . . If you have a Mac II, the speed issue is much less
(disk speed begins to dominate) and MPW is not as much of a burden.

Personally, I use both. When I'm writing something quick and dirty
(print the number 1 to ten on the screen) I use LSC for its superior
compiling and better interface. For projects where I need speed, the
project is huge, I use MPW....

            *    *    *

>From: [e-mail] (William Edward Woody)

I personally use MPW C, and the MPW environment for the Macintosh,
available from APDA. . . .

The advantages include:
    *  Support of the 68020/68881 processor already available
    *  The Greenhills C compiler used is one of the fastest in the
       industry (Apple paid a pretty penny for it...)
    *  UNIX-like development environment (you can create tools which
       can be used from the shell or stand-alone applications--useful
       for testing algorithms and bits of code before inserting it
       into your finished application) Disadvantages include:
    *  No in-line assembler (seperate assembler is included which
       works with the same linker--creating C like functions in
       assembly for placing your 'in-line' code there is fully
       explained.
    *  Huge and complete manual which is damned hard to wade through
       when you are first learning the application.  (I suggest
       buying 'Programming with Macintosh Programmer's Workshop,
       a seperate book which should be available at all your better
       computer bookstores everywhere; it's good to first learn your
       way around the system.)

The cost:  $200 for the MPW shell environment (including ASM and LINK,
       make utilities, and more tools than you can ever learn for
       managing large projects),
       $150 for the MPW C compiler (requires environment, above).
Available: Available only through APDA, the Apple Programmer's and
           Deleloper's Association.  Membership is $25.00, and
       includes a monthly newsletter and substantial discounts
       on a large range of software.
         APDA
         290 SW 43rd Street
         Renton, WA 98055
         [phone]
         CompuServe #73527,27
           I would highly recommend joining them, even if you don't
       buy MPW.  They ship in 3-5 days after phoning in your
       order, shipped Federal Express, as their standard (!!)
       shipping courier.  From them you can buy damned near
       everything you will need as a Macintosh Developer.

            *    *    *

>From: [e-mail] (David Phillip Oster)

LightSpeed C already has a fine assembler built in to it. In particular,
it knows about C objects and C comments.


This is all documented in your LSC manual!

For example:

#include <asm.h>

Handle NewClearHandle(size)long size;{
 asm{
     move.l  size,d0        /* move the size to where the Op sys trap wants
*/
     _NewHandle      CLEAR  /* call the trap with the modifier */
     move.l  a0,d0          /* move to C's function return register */
    } }

**** Just a note to append to this reply: **** On page 10-5 of the main
manual, it says that inline assembly language **** is not
available.    When I saw this a while back, I checked the v2.01 ****
supplement and did not find it listed as a command.  It is in there,
**** but since there is no index, it is hard to find.  See page 17 of
the **** manual supplement. ****                         - Pez

            *    *    *


>From: Richard Siegel <[e-mail]>


. . . Programs written with LightspeedC:

    XPress (Quark)
    Aldus PageMaker (Aldus)
    Adobe Illustrator (Adobe Systems)
    LightspeedC (THINK Technologies)
    Capps Prime Editor Construction Kit (THINK Technologies)
    LaserSpeed (THINK Technologies)
    Canvas (Deneba Software)
    StuffIt (Shareware, Raymond Lau)

There are others, but I don't know them all, and I don't have an
exhaustive list. Oh yes--

    LaserTalk (Emerald City Software)

The point is, several very large (and commercially successful, I might
add) products have been written with LightspeedC, which is good
testimony to its overall usefulness.

        --Rich

            *    *    *

    I hope that this will help anyone else who was in the same position
that I was in: trying to apply knowledge of MS-DOS and UNIX computers to
the Macintosh.

    Also, while I was waiting for responces (a whole 48 hours), I saw in a
book store the whole line of Apple books.  There is one which
particularly caught my attention: _A Programmer's Introduction to the
Macintosh Family_. In there, they talk about MPW and its add-ons, APDA,
and other useful info.

        As far as which C compiler I will be using, I will stick with
Think's Lightspeed C.  Once I start making some money from my
developments, I might purchase MPW and then compare that to the next
version of LSC.

    Thanks to all who replied to my posting.

                        Daniel Pezely
                        [e-mail]
                        University of Delaware


------------------------------

From: [e-mail]
Subject: Re: Programmer's Extender vs. MacExpres
Date: 1 May 88 17:50:00 GMT

    I have not used MacExpress, but I do have considerable experience with
the Programmer's Extender packages from Invention Software Corp. (NOTE:
I helped write some of the code currently contained in the Volume II of
the Extender and am therefore possibly biased)
    The Programmer's Extender comes in two volumes. Volume I's routines are
much like those found in Transkel.  Event Handling, Menus, Dialogs,
Windows, Some  File I/O, etc.  As well as some extra little functions
that might come in handy. Volume II is the more advanced routines for
handling the List Manager (this stuff it VERY NICE!), PICT/Bitmapt
handling, Printing, Extended File I/O, Window Tiling/Stacking, Extended
Text routines, etc.
    Much of the source is included (approx 90% of Volume I, and 75% of
Volume II) in the standard versions or if you want ALL of the source
code they have the Professional Extenders which are MUCH MORE Expensive
but you do get complete source to everything!!
    As far as extendability there are userHooks to everything so that you
can handle things yourself if the standard method is not to your liking
(a good  example of this is WindowUpdates!).
    The only provision when using the routines is that you includes a
copyright notice in your program and in the docs (like what you have to
do with LSP & C) and other than that it's all yours!!
    That's a pretty brief explanation of the packages.  If you are
interested, I can send you a review of the packages that appeared on
GEnie a bunch of months back that gives you an indepth look at the
packages.
--
+---------------------------------+-----------------------------------+
+                                 +  Any thing I say may be taken as  +
+   Leonard Rosenthol             +  fact, then again you might decide+
+   President, LazerWare, inc.    +  that it really isn't, so you     +
+                                 +  never know, do you??             +
+   [e-mail]     +                                   +
+   GEnie:  MACgician             +                                   +
+   Delphi: MACgician             +                                   +
+                                 +                                   +
+---------------------------------+-----------------------------------+


------------------------------

From: [e-mail] (ephraim vishniac)
Subject: Re: Physical Storage Amounts on Different Hard Disks (Size of Folders)
Date: 3 May 88 14:20:56 GMT
Organization: Thinking Machines Corporation, Cambridge, MA

Interleaving has nothing to do with the capacity or usage of the disk.
In fact, interleaving has very little to do with anything except very
low-level performance tweaking.

Space on Macintosh volumes (as in many kinds of file systems) is not
necessarily allocated one sector at a time.  It's allocated in "Volume
Allocation Units."  The size of a VAU is proportional to the overall
size of the disk.  On HFS volumes up to about 32 megabytes (64K
sectors), the VAU is one sector.  So, it's the same on an 800K floppy
and on a 20M hard disk.  Above 32M, the VAU increases by roughly one
sector per 32M.

Your 102M disk probably has an allocation unit of 4 sectors (2K) instead
of 1 sector (.5K).  Statistically, expect a waste of .5 VAU per file.
That's an increase of .75K per file going between the disks you
describe, so you'd see an increase of 1M with about 1300 files. Sound
about right?
--
Ephraim Vishniac                      [e-mail]
Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214

     On two occasions I have been asked, "Pray, Mr. Babbage, if you put
     into the machine wrong figures, will the right answers come out?"


------------------------------

From: [e-mail] (Michael Thomas Niehaus)
Subject: Word Perfect for the Mac
Date: 3 May 88 17:07:53 GMT
Organization: CS Dept, Ball St U, Muncie, Indiana

Well, I have been using Word Perfect on my Mac II for a short time now,
and I have come to the conclusing that it is just one or two versions
away from being a very excellent program.  It still has some problems
right now.  It  seems to have some problems when the spelling checker is
active; double-spaced text doesn't always appear double spaced.  Also,
when editing a header, sometimes lines will disappear from the screen
(even though Word Perfect still knows that they are there).  Anyone from
Word Perfect out there?

There is one feature that I think every Mac program should implement for
we hard disk owners: the ability to set a default folder for all file
saves and retrieves.  This is definitely prevents hard disk clutter when
more than one person uses the same machine.  (I tend to forget to
specify what folder, so I will let the program do it for me.)

With a hard disk, the automatic timed backup feature is so fast that it
is not noticeable.  However, I don't know how well it would do for a
3.5" drive. That could end up being annoying.

The spelling checker works very well, especially compared with the beta
version.  I haven't tried the thesaurus yet.

So what does everyone else think of the package?  We probably will adopt
this software as a standard here at Ball State University, mainly
because we have 200 copies of the IBM version and the VAX version.
--
Michael Niehaus
UUCP: ..!{uunet,pur-ee,iuvax}!bsu-cs!mithomas


------------------------------

From: [e-mail] (Glenn Fleishman)
Subject: Info on EMAC hard drives
Date: 5 May 88 16:55:09 GMT
Organization: Not the opinions of the Yale University Computer Science Dept, New Haven CT  06520-2158

Does anyone have any knowledge of or experience with the EMAC 20Meg hard
drive? In ICON REVIEW's catalogue, they show it at a list value of $995,
but their "low" price is $525.  Does this sound good to those of you who
have purchased 20M drives?  I have no basis of experience at all with
anything but floppy drives.  Any advice (email'ed if not universally
relevant) would be appreciated, as well as info on EMAC and Icon
Review's service.

Thank you.
--
Glenn I. Fleishman, graphic designer & Mac apologist
[e-mail] or through r/Reply
"Andy Warhol lives. I think. Maybe not."


------------------------------

From: [e-mail] (Jeff Shulman)
Subject: A/UX AppleTalk printing
Date: 5 May 88 18:36:13 GMT
Organization: Schlumberger-Doll Research, Ridgefield, CT

Using Sun TOPS we are able to print from our Suns onto any AppleTalk
LaserWriter.  You even have remote printing from other Suns to the print
server Sun via NFS.

Has anyone tried getting A/UX to do remote printing to a Sun?  I called
TOPS and they said they haven't tried it nor is it "meant" to work on
non-Suns.

It *seems* like you should be able to get it to work.  Perhaps?

                                                        Jeff
--
uucp:     ...rutgers!yale!slb-sdr!shulman
CSNet:    [e-mail]
Delphi:   JEFFS
GEnie:    KILROY
CIS:      76136,667
MCI Mail: KILROY

------------------------------

End of Usenet Mac Digest
************************
-------